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METHOD AND SYSTEM FOR SERVER-BASED ERROR PROCESSING IN 
SUPPORT OF LEGACY-BASED USAGE AND BILLING SYSTEMS 

[0001] This application claims the benefit of U.S. Provisional Application No. 

60/210,599 filed June 9, 2000 which is herein incorporated by reference in its 
entirety. 

BACKGROUND 

Field of the Invention 

[0002] The present invention relates to error processing and correction for legacy 

computer systems and applications. More particularly, the present application relates 
to error processing and correction for utilities and telecommunications service 
providers. 

Background of the Invention 
[0003] In many commercial settings a service or product provider (also referred to 

herein as "provider") performs certain services or provides products to its customers 
on one date and then bills those customers at a later date. Often times, the bills are 
cumulative of several days, weeks or months, of usage of the services or products 
offered. Elaborate tracking and billing systems have been developed over time to 
record the customer's usage and generate bills or invoices for delivery to the 
customer. Such tracking and billing systems can become very complex in situations 
where the provider offers multiple lines of services and products, each having 
different rates or prices, or where the provider offers volume discount rates and prices 
or other special offers to customers. The tracking and billing operations become even 
more complex when the provider also serves as an intermediary between the 
customers and other providers. Tracking and billing operations are commonly 



1 



performed in utilities-related industries because of the metered nature of the products 
and services provided to consumers. Such operations are also used in 
telecommunications services to track the use of and to bill for local and long distance 
telephone service and associated enhancements (such as, e.g., caller-id, privacy 
screening, and the like.) Other examples of tracking and billing operations include 
those used in the home entertainment industry such as cable television satellite 
television services, particularly those offering pay-per-view services. 

Traditional tracking and billing operations, i.e., those developed for highly 
regulated industries such as utilities and telecommunications, have been very stable 
systems because they were based on highly customized applications designed to 
perform a limited tracking or billing function for a particular service or industry. 
Software applications used in such tracking and billing systems have been very large- 
scale programs which were designed to operate on mainframe computer systems such 
as provided by IBM or Amdahl. Because of the high customization and the criticality 
of such tracking and billing operations, any changes to the software code usually must 
support all prior functionality. Such established applications are often referred to in 
the art as "legacy systems" because they have been handed down from one generation 
of software to the next, generally without major changes that would affect existing 
capabilities. As a consequence, these legacy systems have been very difficult to 
upgrade or integrate with other systems as the industry has evolved. To maintain 
stability and compatibility, the software applications have been strictly controlled so 
that any changes to the code require much fault-testing and operational verification 
prior to actual implementation in the live systems. 
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[0005] Conventional billing and tracking architectures typically comprise multiple 

billing and tracking sites with multiple billing and tracking systems deployed at each 
site. As discussed above, because many of these billing and tracking systems are 
legacy systems with little or no integration, changes at one site or in one billing and 
tracking system may need to be repeated at other sites or in other systems. Figure 1 A 
is a schematic diagram showing a typical layout for conventional billing and tracking 
systems for multiple sites. Tracking and billing site 1 10 has one or more computers 
systems for collecting usage data and generating billing records. In Figure 1 A, site 
1 1 0 has computer system 1 12 for collecting raw usage data from metered systems or 
services (not shown in Figure 1). Raw usage data from computer system 1 12 is 
provided to computer 1 14 for error detection and other data processing before being 
provided to computer system 1 16 for final processing of billable usage data which is 
then sent to a bill generator (not shown in Figure 1 A). As shown in Figure 1 A, other 
tracking and billing sites 130 and 140 include multiple computer systems providing 
essentially the same functions as provided by computer systems 1 12, 1 14 and 1 16 at 
tracking and billing site 110. Computer systems 1 12, 1 14 and 116 shown in Figures 
1 A and IB may comprise a single computer system having one or more non- volatile 
data storage media. 

[0006] Figure IB shows a more detailed schematic diagram of the computer systems 

and the functions performed by each system at conventional tracking and billing 
system 110. Raw usage data received from metered systems (not shown in Figure IB) 
is stored in database 1 1 7 on computer system 112. The raw usage data from database 
1 17 is routinely provided to computer system 1 16 for by error/usage function 1 18. As 
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used herein, a function comprises the computer hardware and software associated 
with a general process performed on a computer system. Function 118 passes valid 
usage records on to computer system 1 16 for storage in database 120. The usage 
records stored in database 120 comprise the billable usage records that are 
subsequently fed to a bill generator system (not shown in Figure IB). Function 118 
also sends records having usage errors to computer system 1 16 for storage in database 
122. Correction function 123 on computer system 1 16 analyzes and corrects the 
records stored in database 122 then sends the corrected records back to computer 
system 112. The corrected records are stored in database 124 on computer system 
112. Computer system 1 12 sends the corrected records from database 124 to 
computer system 1 14 for processing by error/usage function 118 along with the raw 
usage records from database 117. 

[0007] Because error correction function 123 is embedded into computer system 116, 

changes related to error correction processes cannot be rapidly implemented. Any 
such change would need to be thoroughly tested to ensure no software coding errors 
or other vulnerabilities have been introduced in the operational system. Even when 
such a change is successfully implemented at a site, the change is only available at 
that site. If the billing and tracking function is also carried out at other sites, the 
changes would have to be duplicated independently at each site. Moreover because 
each site may have its own unique configuration, the system testing described above 
would need to be duplicated at each site. 

[0008] Error processing systems are a critical component of both tracking and billing 

systems. This is especially true when the tracking or billing operation supports 
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hundreds of thousands, even millions, of customers and when the value of each 
individual service and product sold is insignificant. In such cases, manually 
correcting errors in individual discrepancies would be too costly in light of the small 
revenue associated with the individual item or customer. Accordingly, software 
applications for automating resolution of errors in tracking or billing records have 
been incorporated into legacy systems. Because the error processing systems have 
been imbedded in the legacy system, changes to the application have been subject to 
the same rigid controls described above. 
[0009] Prior to deregulation of the utilities and telecommunications industries, there 

was little need for rapidly implementing changes in the tracking or billing 
applications to accommodate changes in business goals or operational procedures. In 
today's competitive environment, service providers must be able implement changes 
rapidly as the business expands into new territories or otherwise transforms its 
operations. 

[001 0] Due to the problems/limitations with the legacy error processing systems 

described above, as well as the need to have an effective system to handle error 
messages from multiple sources, a new wholesale error processing and correction 
system is needed. 

SUMMARY OF THE INVENTION 

[001 1 ] In one embodiment, the present invention provides a system for processing 

and correcting errors in a usage data collected on a legacy system for use in a bill for 
a metered service, said system comprising a server computer comprising a usage 
errors database, a load function, a master database, a strip function and a corrected 
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usage database, wherein said usage errors database received a plurality of usage error 
data from the legacy system, and wherein said load function transfers the plurality of 
usage error data from the usage error database to the master database for processing, 
and wherein the strip function transfers corrected usage data from the master database 
to the corrected usage database, and wherein the corrected usage data is provided 
back to the legacy system for use in the bill for the metered service. 
[0012] In another embodiment, the present invention comprises a method for 

processing and correcting errors in usage data on a system separate from the legacy 
systems used to record usage data and the generate bills for customers served by the 
service provider. By using system apart from the legacy system, the present invention 
provides much more flexibility for enacting special billing discounts in response to 
competitive pressures. 

[0013] The present invention provides a graphical user interface with pre-defined and 

ad hoc query capabilities enabling users to locate particular error records or cases of 
error records. 

[0014] The present invention comprises a master database running on a server, 

wherein the database comprises a plurality of pre-defined rules for processing and 
correcting errors in usage data meeting the criterion of one of the rules. After a rule 
has been applied to an error record, the record may be sent back to the legacy system 
for inclusion in the billing processes thereon. 

[001 5] An administrator graphical user interface is provided for managing users, 

rules, and transactions on the error processing system of the present invention. An 
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administrator may approve, deny or delay processing on certain rules or transactions 
according to one or more threshold identifiers that the administrator may set up. 
[0016] A reporting system is also provided by the present invention to provide users 

with a plurality of pre-defined and ad hoc reports. The reporting system may be 
accessed directly by users who can direct the format, content, and output device for 
the reports. Unlike prior legacy error processing systems, the present invention does 
not require extensive knowledge of the internal database structures to generate useful 
reports. 

DESCRIPTION OF THE DRAWINGS 

[0017] Figure 1 A is a schematic diagram showing systems engaged in error 

processing and correction using legacy systems. 
[001 8] Figure IB is a more detailed schematic diagram showing the systems and 

functions performed at each site shown in Figure IB. 
[001 9] Figure 2A is a schematic diagram showing systems for error processing and 

correction according to an embodiment of the present invention. 
[0020] Figure 2B is a more detailed schematic diagram showing the systems and 

functions performed by a server according to the present invention. 
[002 1 ] Figure 3 is an exemplary view of an initial screen provided to a user in an 

embodiment of the present invention. 
[0022] Figure 4 is an exemplary view of the initial screen provided to a user in an 

embodiment of the present invention, wherein the user is selecting a site from a drop- 
down menu. 
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[0023] Figure 5 is an exemplary view of a usage summary screen provided to a user 

in an embodiment of the present invention. 
[0024] Figure 6 is an exemplary view of a usage error overview screen provided to a 

user in an embodiment of the present invention. 
[0025] Figure 7 is an exemplary view of a usage summary screen provided to a user 

in an embodiment of the present invention wherein the user has expanded the error 

code tree. 

[0026] Figure 8 is an exemplary view of a usage summary screen provided to a user 

in an embodiment of the present invention wherein the user has further expanded the 
error code tree. 

[0027] Figure 9 is an exemplary view of a usage grid display screen provided to a 

user in an embodiment of the present invention, 
[0028] Figure 10 is an exemplary view of a usage display screen provided to a user in 

an embodiment of the present invention. 
[0029] Figure 1 1 is an exemplary view of a case summary screen provided to a user 

in an embodiment of the present invention. 
[0030] Figure 12 is an exemplary view of a usage grouping screen provided to a user 

in an embodiment of the present invention. 
[003 1] Figure 1 3 is an exemplary view of a pending transaction screen provided to a 

user in an embodiment of the present invention. 
[0032] Figure 14 is an exemplary view of a main screen provided to an administrator 

in an embodiment of the present invention. 
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[0033] Figure 15 is an exemplary view of a transaction approval maintenance screen 

provided to an administrator in an embodiment of the present invention. 
[0034] Figure 1 6 is an exemplary view of a detail display screen provided to an 

administrator in an embodiment of the present invention. 
[0035] Figure 17 is an exemplary view of a report for User Transaction Report by 

Site/Employee with Comments. 
[0036] Figure 1 8 is an exemplary view of a report for User Transaction Report by 

Site/Employee with Comments and Case-Definitions. 
[0037] Figure 19 is an exemplary view of a report for BRAVO CATTS Usage - 

Charge NPA/NXX. 

[0038] Figure 20 is an exemplary view of a report for BRAVO CATTS Usage - 

Originating NPA/NXX. 
[0039] Figure 21 is an exemplary view of a report for BRAVO CATTS Usage - 

Terminating NPA/NXX. 
[0040] Figure 22 is an exemplary view of a report for Delete Summary Report. 

[0041] Figure 23 is an exemplary view of a report for Write-Off Summary Report. 

[0042] Figure 24 is an exemplary view of a report for Transmission Reports, 

[0043] Figure 25 is an exemplary view of a report for MOU 1 5-60-90 Report. 

[0044] Figure 26 is an exemplary view of a report for PEGS 15-60-90 Report. 

[0045] Figure 27 is an exemplary view of a report for Aging - DA vs. Other Report. 

[0046] Figure is an exemplary view of a report for 28 Transacted and Unworked 

Usage Other than IBIS Report. 
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[0047] Figure 29 is an exemplary view of a report for Error Master File - MPB 

Report. 

[0048] Figure 30 is an exemplary view of a report for Usage Cases On Hold Report. 

[0049] Figure 3 1 is an exemplary view of a report for Aging Bill Guarantee IOS/72 V 

Report. 

[0050] Figure 32 is an exemplary view of a report for Aging Bill Guarantee 

OTS/CABSTT Report. 

DETAILED DESCRIPTION OF THE INVENTION 

[005 1] A schematic diagram showing the architecture for an embodiment of the error 

processing system of the present invention is shown in Figure 2A. As shown in 
Figure 2 A, tracking and billing sites 210, 220, 230 and 240 feed data to site 250 for 
processing and correcting errors by one or more centralized server computers, e.g., 
server computers 252 or 254. 

[0052] Figure 2B is a more detailed schematic diagram showing how error processing 

and correction is handled in an embodiment of the present invention. The computer 
systems and databases shown at site 210 in Figure 2B are the same as those shown at 
site 1 10 in Figures 1A and IB. That is, computer 212 corresponds to computer 1 12, 
raw usage database 217 and corrected usage database 224 correspond to raw usage 
database 117 and corrected usage database 124, respectively. Similarly, computer 216 
corresponds to computer 116, billable usage database 220 and usage errors database 
222 correspond to raw usage database 120 and corrected usage database 122, 
respectively. Finally, computer 214 corresponds to computer 114 and error/usage 
function 218 corresponds to error/usage function 1 14. Note however, that computer 
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216 does not include a corresponding correction function 123 for correcting the data. 
Instead of locally processing and correcting errors in the data, the data is sent to a 
server computer 252 at a centralized site 250 for processing and correcting errors of 
the usage data* Server computer 252 may be any server computer suitable for 
receiving and processing data from the various tracking and billing sites. In an 
embodiment of the present invention, server computer 252 is a Windows NT server. 
As shown in Figure 2A, data from more than one site may be processed by a single 
server computer. That is, server computer 252 may process data from both sites 210 
and 220. 

[0053] Usage errors from database 222 on computer system 216 are sent from site 

210 to server computer 252 for storage in database 260. In an embodiment of the 
present invention, the usage errors are transmitted from each site to its designated 
server on a daily basis. This data is then loaded into master database 261 by load 
function 262. Master database 261 can be implemented using any relational database 
server application. In an embodiment of the present invention, master database 261 is 
a Microsoft SQL Server 7.0. Although a single server may process data from multiple 
sites, in a preferred embodiment, separate master databases are used to process the 
data. Accordingly, server computer 252 may include more than one master database. 
After the error data has been corrected, it is sent back to the local tracking and billing 
site from which it was received. In an embodiment of the present invention, a 
corrected error file is pulled from master database 261 on a daily basis by strip 
function 263. Strip function 263 conforms the data to an appropriate format and stores 
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the corrected data in database 264. As shown in Figure 2A, data from database 264 is 
then sent back to site 210 for entry back into the billing stream process. 

[0054] The interface between the data and the users is provided via user function 265. 

In an embodiment of the present invention, user function 265 is a PC-based graphical 
user interface (GUI). Error correction according to the present invention can be 
applied to individual errors, as well as to cases or classes of errors wherein the user 
can define the characteristics of the case or class. The error processing system of the 
present invention is designed to handle all types of wholesale usage ( for example, in 
the telecommunications industry, common legacy wholesale usage systems include 
CABS, MPB, UNE, PSP, Wireless, etc.). 

[0055] In the error processing system of the present invention, report generation may 

be a user defined process. Report function 266 allows users to define reports, the 
frequency at which the reports are generated and the media on which the reports are 
to be produced. Report function 266 provides users with the ability to quickly 
determine the overall state of the error master file and provide comprehensive 
statistical information. Also, historical data may be maintained for a period of time, 
e.g., six months, providing the capability to recreate deleted usage as well as 
providing access to detailed information on the history of every message. Report 
function 266 thereby reduces the need for manual intervention by a system 
administrator to generate reports on behalf of users. 

[0056] Administration function 267 may be used to control access to the error 

processing and correction system of the present invention. Administration function 
267 is preferably a GUI application for ease of use. Administrator function 267 may 
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also be used to grant or deny approval to correct certain errors as determined by 
parameters set up by administrators. 
[0057] The present invention provides several advantages over conventional error 

correction systems. First, the present invention allows batch processing of errors. 
Second, the present invention provides the GUI environment noted above to allow 
easy access to system user. Third, the present invention includes the administrator 
function noted above to enhance security and general administration of the error 
correcting system. Finally, the present invention includes a reporting function that 
provides comprehensive access to the data being processed and corrected. 
Characteristics associated with each of these benefits are described in greater detail in 
the following sections. 

1. Batch Processing Characteristics 
a. Rules 

[0058] Rules can be set up in the error processing system of the present invention to 

transact usage automatically. A rule identifies usage by criteria and applies a 
transaction to the usage. For example, an administrator could set up a rule that would 
always release usage errors that came into the error processing system of the present 
invention having a specific identifying code or site ID, etc. In a preferred 
embodiment, only administrators can build rules in the error processing system of the 
present invention. Also in a preferred embodiment, rules include a description of the 
rule and have start and end dates that meet the following criteria: 

[0059] Start Date : Cannot be earlier then current date and can be up to one month in 

the future. 
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[0060] End Date : Cannot be earlier than current date and can be up to one year in the 

future. 

[006 1 ] Maximum Duration : The maximum amount of time that a rule can be in effect 

is one year. 

[0062] An administrator can view a screen showing all rules that are within a given 

time frame of expiring and those that have already expired. This screen also allows 
the administrator to extend, modify or delete rules. 

[0063] A rule report is available to users and administrators through the GUI user 

function. This report displays all the rules that are defined in the error processing 
system of the present invention. This report shows how much usage has been 
transacted by each rule since it was added to the error processing system of the 
present invention, the date the rule was created, as well as the person who created. 

[0064] When a rule expires, but has not been extended, modified or deleted, it will no 

longer perform action on the records that it applies to. Those records will flow 
through the normal load process. That is, if other unexpired rules are applicable, they 
will be applied to the records as necessary. 

[0065] Changing the end date can extend a rule that has expired. However, a rule that 

has been deleted cannot be reused. An expired rule can be copied into a new rule, but 
it cannot be reused. 

[0066] Cases and rules can be added or deleted at any time. When a case/rule is 

deleted, the error processing system of the present invention will attach a total 
messages and minutes of use (MOU) figure with it for historical purposes. A 
comment is required on a rule when it is created and when it is deleted. Deleted 
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rules/cases are maintained as long as there is related usage in the system for historical 
and root cause analysis purposes, 

b. Load Thresholds 

[0067] System thresholds can be associated with each error code processed in the 

load process. If any of these thresholds is exceeded, an email can be sent to one or 
more administrators describing the threshold that was exceeded. The threshold values 
can be maintained by the administrators and can be modified as needed using the 
administrative screens. In a preferred embodiment, defined thresholds include: 

[0068] Last Load All Sites Threshold : If the total number of records related to a 

particular error code loaded in the last load exceeds a defined value, this threshold is 
met. The last load all sites threshold include records received from all sites. A default 
value can be assigned for any error code that does not have a specific assigned value. 

[0069] Last Five Loads All Sites Threshold : If the total number of records (all sites) 

for a particular error code loaded in the last five loads exceeds a defined value, this 
threshold is met. 

[0070] Last Load Single Site Threshold : If the total number of records loaded in the 

last load for a single site exceeds a defined value, this threshold is met. 

c. Notification Of Undefined Error Codes/Record Types 

[0071 ] In a preferred embodiment, a warning email can be issued to administrators in 

certain situations. For example, a warning message may be sent when a record layout 
is received that is not defined for processing according to the present invention. In 
another example, a warning email mail be sent when an error code is detected that is 
not defined. 
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d. Case Processing 

[0072] As noted above, the error processing system of the present invention can 

assigns new usage to existing cases, if the criteria match. 

e. Transmission Statistics 

[0073] Transmission statistics may be stored in the error processing system of the 

present invention history for all loads and strips. 

f. User Defined Criteria To Load Data To Files Instead Of 
GUI 

[0074] Users can identify records that should not be loaded to the GUI for correction. 

These records are spun off to separate files and maintained for the designated 
retention period. 

g. Handles Variable Length Records And Modules 

[0075] The error processing system of the present invention can handle variable 

length records as well as modules attached to these records as long as they are defined 
in the record layout portion of the master database. Administrators can define new 
record layouts using the administration function. 

h. Converts Data From EBCDIC To ASCII And Back 

[0076] The error processing system of the present invention has logic that can convert 

data from EBCDIC to ASCII and back again. 

i. Controls Included To Balance Between Sending And 
Receiving Programs 

[0077] The error processing system of the present invention has controls in place to 

balance between sending and receiving programs from mainframe to server and back 
to mainframe. Any out of balance conditions can be sent via email to system 
administrators. 
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j. Groups Corrected Records And Sends Them To 
Appropriate Mainframe Site 

[0078] One (or more) times per day, corrected records are pulled off of the error 

processing system of the present invention and put into a file that is then transmitted 
to the bill stream and mainframe site that it originated from. Users may also redirect 
usage to another bill stream or to some other site as desired. In a preferred 
embodiment, the transmission between server and mainframe is accomplished via 
ConnectDirect available from Unitech Systems, Naperville, Illinois, 
k. Moves Usage From One Site To Another 

[0079] The error processing system of the present invention provides the capability of 

moving usage from one processing site to another processing site. 
1. History 

[0080] The error processing system of the present invention maintains history 

information on all usage that has been processed. By using the history information for 
a record or case of records, the original record can be seen and every transaction 
performed on that usage can be viewed, along with the comments entered, 
m. Controls 

[0081] Controls within the error processing system of the present invention can be 

used to insure data integrity through internal and external balancing; and restricted 
system access. System access can be restricted using network security features such 
as those provided by NOVEL or Windows NT network operating systems and third- 
party virus or intrusion detection systems. Access may also be restricted through user 
security features built into the applications comprising the present invention. 
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[0082] External Balancing - External balancing may be used to insure all records 

generated by one system are transmitted successfully across platform boundaries to a 
receiving system. Such balancing insures data is not lost or duplicated in the 
transmission process. In a preferred embodiment, the error processing system of the 
present invention uses products available from Unitech Systems, Naperville, Illinois, 
for external balancing. This balancing takes place during the transmission of data 
from the mainframe to the server and from the server to the mainframe. External out 
of balance conditions cause the mainframe job to end and an email message can be 
used to alert the system administrators, 

[0083] Internal Balancing - Internal balance procedures can be used to insure the 

database is not corrupted through the duplication or omission of usage. Balancing 
occurs whenever usage is added to or stripped off any of the databases used by the 
present invention. In a preferred embodiment, internal load balancing is performed 
using Unitech Summary, available from Unitech Systems, Naperville, Illinois. 
Internal out of balance conditions can be reported to system administrators via email. 

[0084] System Access - In an embodiment of the present invention, access to the 

error processing system data can be controlled through the use of four levels of 
security. The first level, the network operating system, e.g., Novell, limits users to 
those individuals defined to Novell. This places control over who can access the 
network, which servers within the network can be seen and what directories can be 
updated. The second level, system security is provided by setting up the server 
computer to allow limited access. In a preferred embodiment only system 
administrators or other trusted users are allowed direct access to the applications and 
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data on the server computer. In this embodiment, regular users may access the 
databases only through the application. Further, the server system may be set up to 
send email, but not to receive email or any transmissions except through the 
application. This feature eliminates any threat of corruption by a virus or other 
malicious threats. The third level, SQL Server security provides the primary 
protection of the databases within the error processing system of the present 
invention. In order for an individual to have any access to the error processing system 
of the present invention, they must be identified to SQL Server as a user and their 
'rights' to the database defined. The fourth level, the application security features, 
requires that a user be defined within the system with the type of access needed, e.g., 
Read Only, Update and Administrator. 
2, User GUI Characteristics 

a. Sign-On Screen 

[0085] The user GUI provides a sign-on screen which is used to control access to the 

system as described above. Users enter a user ID and a password to log in and gain 
access. 

b. Presentation Of Errors (Error Code Tree) 

[0086] Usage data is displayed via the GUI using a hierarchy to simplify data 

analysis for the users. The hierarchy, also known as an error code tree allows users to 
zero-in on the pertinent information needed to analyze particular errors. In a preferred 
embodiment, the display hierarchy includes the levels show in Table 1. 
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[0087] Also, in a preferred embodiment, the error code tree can be visually enhanced 

by adding interactive features such as displaying a brief description of that error code 
when the cursor is floated over an error code on the tree, 

c. Summary Screen 

[0088] Once the user logs on to the system, a summary screen is displayed providing 

statistics about the error database for that site. The summary screen displays records, 
messages, MOU, Pegs and date range at the error code level. The screen may also 
provide this information (by error code) for usage that is unworked (not transacted), 
transacted and usage that came into system on the last load. A grand total line for the 
entire error database may also be displayed on the summary screen. The date and time 
of the last load for that site may also be displayed on the summary screen. 

d. Usage Error Overview 

[0089] When the user clicks on a particular error code, the GUI provides a summary 

screen for that error code. The summary screen contains records, messages, MOU, 
Pegs and date ranges for Current usage, Usage on Hold, Transacted usage and Other 
usage for that error code. 
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e. Grouping Screen 

[0090] The GUI can provide many options for grouping usage 4 as you go' on the 

error grid. For example the grouping screen may include features to: add or remove 
fields on the error grid; filter records based on message date range; view only usage 
that has come in on the last five cycles; change the order the records are displayed; 
populate specific values in fields and only view records that match that criteria; look 
for specific record types; and to save groupings defined for each error code. 

f. Error Grid 

[0091] Users may define what information is displayed on the error grid, including 

the order of display for each error code. The errors having a particular error code 
(either as part of a user defined 'case' or not) are summarized and displayed 
according to that definition. The definition (per error code) can be changed during 
daily processing to change the presentation of the data. Administrators can create, 
change and delete error code display definitions via the administrator GUI screen. 

g. Cases 

[0092] Cases are records that are grouped together because they meet a certain 

criteria. Normally, usage that is grouped together in a case represents one problem. 
When that problem in resolved, all of the usage in the corresponding case can be sent 
to bill. User cases can be set up at the error code level. Per error code, usage that falls 
within a defined case is displayed with that case on the GUI screen. Usage that does 
not fall within any case, will be displayed as * Other' within that error code. 

[0093] User cases may be built using any suitable process. In an embodiment of the 

present invention, user cases may be built using user function 265. 
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Detail Screen 

[0094] The error processing system of the present invention allows display of each 

record in error at a detail level While investigating usage, the user can double click 
on a line in the error code display grid and go to the detail information screen. This 
screen shows all fields for the first 50 records contained in that group of usage on the 
selected grid line. On the detail screen, each record's unique record ID number is 
displayed. The record ID can be entered in the search input box which will then 
display only that record for investigative purposes, 
i. Case Summary Screen 

[0095] An embodiment of the present invention may also include a case summary 

screen including information such as: error code; case number; case description; total 
messages; total MOU; date the case was created; start and end date of the usage in the 
case; date that usage was last added to this case; and the user who created the case. 

[0096] Using the case summary screen, a user may view a default display showing 

only cases created by the user that is logged in, or may view a display of all cases, 
regardless of who created it. The user may sort the records displayed based on error 
code, case description, user, messages, MOU, dates, etc. The user may display cases 
based on selected criteria. For example, the user may display all active cases, only 
cases that contain usage, only cases with no usage on them, only cases created by 
users, or only cases created by administrators. The summary screen allows the user to 
input other criteria, such as IBIS number, trouble ticket number or work request 
number and display all cases related to that input. 
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Transactions 

[0097] Transactions are used to change usage on the error processing system of the 

present invention. Transactions include, e.g., delete; write off (WO); release and 
change. In an embodiment of the present invention, transactions can be performed by 
rules set up to automatically transact usage as it comes into the error processing 
system. Alternatively, cases of usage can be built on an ad hoc basis and transacted 
via the user GUI. 

k. Pending Transactions 

[0098] There is a screen on the GUI showing all pending transactions (transactions 

that have been entered that day). This screen includes transactions entered by the 
users through the GUI and transactions generated by rules. There is an option on this 
screen to delete any transactions that the user created and later decides not to process. 
L Comments 

[0099] Comments can be entered at the case level to indicate the status of a particular 

case and what action has been taken on it. When entering a comment, the user selects 
a standard comment and also has the ability to put in additional information as an 
explanation. Multiple comments can be entered for a case. Comments are used to 
document IBIS cases sent, trouble tickets, work requests, etc. that are associated with 
that group of usage. When a user enters a transaction, a comment is required. 

[00100] On the GUI, if the user clicks on a case, the comment, or multiple comments 

are displayed. The most recent comment is displayed first, with any other comments 
following it. The Comment fields that are displayed include: Date/Time the Comment 
was added, Comment Type, Comment freeform, User that entered comment. Cases 
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can be pulled up on the GUI by entering an IBIS number, trouble ticket number, or 
work request number that was entered as part of a comment. 

m. Approval Thresholds 

[00 1 0 1 ] Different transactions can have thresholds set up in the error processing 

system of the present invention to identify transactions that require administrator 
approval. In a preferred embodiment, approval thresholds include those shown in 
Table 2. 



Threshold 


Criteria 


Delete 
Write Off 
Release or 
Change: 


Group of records > 25 messages OR > 100 MOU 
Group of records > 6,500 messages OR > 20,000 MOU 
Group of Records that is > 3 1 days old AND (> 40,000 
MOU OR 13,000 MSGS) 



Table 2 



on [001 02] If a threshold is met, the user receives a message box when they are 

H : completing the transaction telling them that a threshold has been exceeded. Daily, 

before the transactions are pulled, the supervisor views a 'Transactions Requiring 
Approval' screen listing all activity for that day requiring administrator approval. In a 
preferred embodiment, this screen includes comments, case ID, case description, error 
code, name of person performing the transaction, MOU, messages and date of 
transaction and date range of usage. Further, if a line on this screen represents a 
change transaction, the screen offers the capability to view one record on that 
transaction to see what fields were changed and the new value for those fields. 
[00103] The administrator viewing the 'Transactions Requiring Approval' may 

approve the transaction, allowing the transaction to be included in the records to be 
sent back to the mainframe. The administrator may also disapprove the transaction 
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which will delete the transaction, preventing its transmission back to the mainframe. 
Finally, the administrator may choose to do nothing which leaves the transaction in 
pending status. 

[001 04] These thresholds are maintained in a table on the error processing system of 

the present invention. Administrators can change the defined thresholds through an 
administrative screen. 

3. Administrator GUI Characteristics 

[0100] The administrator GUI provides a simple interface allowing administrators to 

manage the error processing system of the present invention. An administrator can be 
any user having administrator permission on the system. For example, an 
administrator may be a supervisor or other person responsible for making decisions 
concerning how to handle special cases that arise in the error correction process. 

a. Case Definition 

[0101] Cases and rules can be viewed, edited, added and deleted via the 

Administrator GUI. Further, cases and rules can be tested before being saved to 
ensure that they do not result in erroneous transactions. 

b. Transaction Approval 

[0102] As described above, when certain thresholds have been reached, a transaction 

may require administrator approval. The administrator may list transactions waiting 
for approval for all sites. The administrator can choose to view transactions by site, 
and either list all transactions for a site or only those waiting for approval. 
Transactions generated by rules can also be displayed. The administrator can approve, 
reject or postpone action on transactions as described above. 
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c. Threshold Definition 

[0103] The administrator GUI provides a screen to allow the administrator to define 

thresholds for the system. This screen allows the administrator to view, change, add 
or delete both balancing and approval thresholds, described above. 
d« Record Layout Definitions 

[0104] The administrator GUI provides a screen for displaying record layouts and 

field definitions. The administrator view, change, add or delete record layout via this 
screen. Further, fields on a layout can be linked to search fields. 

e. Error Code Definition 

[0105] Error codes can be viewed, changed, added or deleted via the administrator 

GUI. 

f. Access Permissions 

[0106] An administrator can also manage the access permission granted to other users 

of the system In an embodiment of the present invention, there are four levels of 
access permissions: 

[01 07] No Access permission means a user cannot even log on to the error processing 

system of the present invention. 
[0108] Browse access permission allows a user to view the data in the error 

processing system of the present invention, but perform no action. 
[01 09] Update access permission allows a user to view data, enter cases, correct 

errors, build and run queries, etc. 
[0110] Administrator access permission allows a user to appro ve/delete transactions, 

build rules and cases, add new error codes, define record layouts, etc. 
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[01 1 1] Using an access permission screen, an administrator can display, change, add 

and delete users and their permissions within the system, 
g. Field Definitions 

[01 12] In a preferred embodiment there are at least two indicators associated with 

every field in the error processing system of the present invention. One indicator 
identifies whether or not a field may be updated at all and the other indicator 
identifies whether or not such updates require administrator approval or access 
permission before being implemented. These indicators can be updated by the users 
with the administrator GUI. 

4. Reporting Characteristics 

a. Reporter 

[0113] The error processing system of the present invention reporter gives end users 

the ability to run pre-defined reports with great flexibility by allowing many report 
parameters to be input by the user when requesting a report. Reports can be viewed 
online or sent to a printer. There is also an option to allow critical reports to be batch 
processed for automated report creation. 

b. Ad Hoc Query Capability 

[01 14] For advanced users who have SQL experience, the capability to write and 

execute queries using standard SQL commands is available. This provides the highest 
degree of flexibility possible. 

c. End of Month Processing 

[0115] A monthly data feed to FDB provides financial information about the value of 

any usage that was written off during the month. Data is also provided reflecting the 
value of unworked usage that resides in the error processing system of the present 
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invention. The value provided is approximate because, after the usage has been 
transacted, some of it may not be billable. Accordingly, the actual value of unworked 
usage cannot be determined until after the usage is investigated and processed. 
SPECIFIC EMBODIMENT OF THE PRESENT INVENTION: BRAVO 

[0116] In the sections below, a specific embodiment of the present invention is 

described. This embodiment is used for error processing in support of a 
telecommunications provider. The embodiment described is known as the BellSouth 
Industrial Billing Reject and Verification Online (BRAVO) application. 

[0117] The BRAVO error processing system is a client/server based PC application 

supported by SQL Server databases. The goal of BRAVO is to provide increased 
functionality, flexibility and reliability of error processing at a much lower cost. 
BRAVO relocates error data to NT servers and gives the error processing assistants 
access to this data using a user-defined PC based GUI screens developed in Visual 
Basic. 

A- BRAVO User GUI 
1. GUI Features 

[01 18] The BRAVO application user GUI provides a simple interface to the error 

processing system shown in this embodiment. Figure 3 shows an example of the 
initial user screen presented to users of the BRAVO application after successfully 
logging into the system. The user may click on drop down box 300 to select a usage 
type. Examples of usage types include: CABS Detail, CABS Summary (i.e., Meet 
Point Billing (MPB)), CMRS Detail, and CMRS Summary. The user may also click 
on drop down box 400 to select a specific site, as shown in Figure 4. After site and 
usage type are selected, usage summary screen 500 is displayed as shown in Figure 5. 
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[01 19] The right half of usage summary screen 500 includes several items of interest: 

information area 502 which includes the user's name, time and date, and site selected; 
last load data 504, which includes the date and time the last BRAVO load occurred; 
grand totals 506 for usage errors which includes data fields as shown in Table 3; and 
individual error code status 508 which includes totals for new, unworked, transacted, 
and grand totals as shown in Table 4. All of these totals can be categorized by record 



count, message count, MOU count, peg count, and date range. 



Total Fields 


Description 


Records 


Total number of records on the error 
file 


Msgs 


Same as Records for detail usage 


MOU 


Minutes of Use total 


Pegs 


Total number of peg counts on the 
error file. Peg counts are associated 
with query type records, like LIDB - 
FGL, IOS - FGS, 800 Database, SCP 
Query billing, etc. 


From-To Date 
Range 


From and To dates of the usage on 
the error file 


Table 3 


Error Code Status 


Description 


New 


New error records from last load for 
BRAVO 


Unworked 


Existing error records that have not been 
worked (transacted) prior to the last load 
for BRAVO 


Transacted 


Error records that have been worked 
(transacted) but not yet pulled for the day 


Totals 


Total usage for individual error codes 



Table 4 



[0120] The left side of usage summary screen 500 shows error code tree 510. Error 

code tree 510 groups errors by specific error type. Error types include format errors 
(e.g., failed edits such as 'must be numeric' or must be 0 or 1, etc.), reference errors 
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(e.g., errors related to reference files, such as the CEO file, IBIS file, etc.) and guide 
errors (e.g., error where the usage cannot guide to an account). 
[0121] When a user moves the cursor over an error code, the cursor changes to a hand 

with a pointing index finger indicating a link to another screen. In addition, a message 
is displayed showing a brief description of the error code. When the user single-clicks 
on the error code, the right side of summary screen 500 changes to display an 
overview of this specific error code. Usage error overview screen 600 (shown in 
Figure 6) includes a brief description of the error code. Usage error overview screen 
600 may also include a more detailed description of the error condition. Usage error 
overview screen 600 displays a matrix showing the status of error records for this 
particular code. 

[0122] In addition to the error usage overview, the user may obtain additional 

information concerning the error code by expanding error code tree 510 for the code 
as shown in Figure 7. That is, the user may open the error code by a single click on a 
plus (+) sign next to an error code in error code tree 510, or a double-click on the file 
folder/cabinet or error code shown in the tree. When the error code is opened, several 
file cabinets are displayed, as shown in Figure 7 for the error code 4 SO.' The file 
cabinets provide a grouping of the records according to the categories shown in Table 
5. 



Category 


Description 


Current 


Displays a list of cases built by Administrators that are not on Hold 


Hold 


Displays a list of cases that have been built and put on Hold 


Other 


Displays a list of usage that has not been transacted or put into a 
Hold case (similar to the ARIES PF2 Scoped Screen) 



Table 5 
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[0123] Single clicking on one of the cabinets reveals more information related to 

errors in the particular category selected. This additional information is displayed in 
usage error overview screen 512 on the right side of the screen. After further 
expanding error tree 510 (e.g., by double-clicking on a file cabinet) additional file 
folders of are displayed, as shown in Figure 8. Additionally, single clicking the plus 
sign (or double-clicking the folder) displays the additional data in the folder, as 
shown in Figure 8. The information in the folder will contain entries/cases for that 
particular error code. The bottom line of the screen will show the error code selected, 
what type of error it is (Format, Reference, or Guide), and a short description of the 
error code. Single clicking on the individual error case displays information about 
that case in the information area 502 and in the detail area 800 (below the usage error 
overview area 600) as shown in Figure 8. 

[0124] Each error record is assigned a unique case number which begins with either 

'IF for user case, 6 A ? for an administrator case, or 6 R' if a case is generated from a 
Rule. The bottom line of the screen changes to show the case identity, what category 
of error it is (Current, Hold, or Other), the number of comments, in addition to the 
error code selected and a short description of the error code. 

[0125] The individual entries under the 'Hold Folder' have status codes assigned to 

them based on the reason an error record is being held as indicated in Table 6. 
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Status 
Code 


Description 


c 


Error is pending a CEO File update 

The NPA/NXX that needs updating on the CEO File is displayed 
in the number field 


I 


IBIS Case has been issued for further investigation by another 
department 

The case number is displayed in the number field 


T 


TTS trouble ticket has been issued for further investigation by the 

Information Technology (IT) group 

The trouble ticket number is displayed in the number field 


F 


Referred to a Subject Matter Expert (SME) for further 
investigation 


W 


Work Request was entered 

The Work Request number is displayed in the number field 


Other 


Other was entered as comment 

'Other 5 is displayed in the status code and number field 



Table 6 



[0126] When the individual error record is double-clicked, the title at the top of the 

screen changes to: USAGE GRID DISPLAY FOR <Error Code> - Case: 
XXXXXXX - <Status Code> <Number> ? as shown in Figure 9. This is also referred 
to as the Error Grid, The case associated with the record will be displayed on the right 
hand side of the screen. The scroll bars in the window allows the movement for 
viewing the information from side to side and up or down. 

[0127] Usage grid display 900, shown in Figure 9 includes selection area 902 

containing buttons used to perform specific functions when viewing or updating error 
records. Certain buttons in selection area 902 are highlighted only when an individual 
error record is activated. These button include: Overview; Group; Errors Grid; 
Details; UNDO Hold; Hold; Guarantee; Write Off; Delete. Release; and Change, The 
function of these and other buttons are described in greater detail below. 



32 



[0128] Details Button : Double-clicking on a particular record or highlighting and 

single clicking the details button 904 changes the view to the usage display screen 
shown in Figure 10. Specific cases can be located by clicking the arrows at the 
bottom of the screen or by entering the case number in the search data box. An 
occurrence on the error grid may have multiple records. To move from record to 
record, the user can press the arrows in the lower bottom section of the usage display 
screen in Figure 10. 

[0129] Cases Button : The cases button 906 allows the user to display the BRAVO 

case listings as shown in Figure 1 1 . Case summary screen 1 1 00 provides the user a 
set of pre-defined options which may be used to select cases by case creator and case 
type. For example, to select administrator cases or cases built by rules only, a user can 
select button 1 102 or 1 104 on case summary screen 1 100. Alternatively, the user may 
input other selection criteria in input box 1 106. Example of other selection criteria 



includes the categories shown in Table 7. 



Category 


Options 


Cases 


My Cases 
All Cases 


Case Type 


User Case 
Admin Cases 


Hold Status 


Cases On Hold 
Cases NOT On Hold 
Both 


Usage 


With Usage 
Without Usage 


Cases With This 
Search Input 


Used for an item that has been entered in the Comment input 
fields. 

Includes IBIS number, NPA/NXX on a Pending CEO File 
change, Work Request number, or Trouble Ticket number 



Table 7 
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[0130] By default, only cases that have usage associated with them will appear on 

error code tree 510. If the 'Without Usage' criterion is selected, the transaction cases 
displayed will be from the last five days in which no new usage is received. This 
means every time a transaction is created, BRAVO builds a case. For five days, 
BRAVO keeps track of this case so that if any usage comes in that meets the same 
criterion, it will combine it with that case. If for five days, no new usage comes in 
meeting that criterion, then the case can be deleted automatically. 

[0131] A record cannot be changed, released, or deleted when in this mode. To make 

such changes in a BRAVO case the user must be on usage grid display screen 900. 

[0132] Summary Button : The summary button 908 (on Figure 9) recalls the usage 

summary screen 500 as shown in Figure 5. This button may be useful when there is a 
need to review the volume of error codes. 

[0133] Overview Button : The overview button 910 displays a usage overview screen 

similar to the one shown in Figure 6. The error code being viewed is displayed in the 
lower left corner of the screen. 

[0134] Group Button : Group button 912 is activated when individual cases are 

selected. When this button is clicked, the display changes to usage grouping screen 
1200, shown in Figure 12. Each error code record(s) has default fields displayed on 
the usage grid display screen 900 (error grid). The group button 912 allows the user to 
change the field criteria on the error grid 900. For example, the fields listed in the 
'Chosen' box 1202 are displayed as the default fields on error grid 900. The user may 
remove or adds fields to the chosen box 1202 for display in the error grid 900. 
Additionally, users may select fields according to particular values using the 
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'Select Fields or Enter Filter Criteria' box 1204. Once the criteria is entered, i.e., 205 
in the NPA criteria box, pressing the 'Refresh' button 1206 updates error grid 900. 
[0135] Other selections can be made via usage grouping screen 1200. For example, 

the usage may be ordered differently, or sorted in particular ways, and search with 
multiple criteria may be performed. Special features are available for the selection 



criteria. The following table lists these features and provides a description. 



Special Features 


Description 


% (Percent sign) 


Wildcard 

Used to represent any portion of a field 
Works on any field in the criteria box 

For example: to view cross boundary offices for Mississippi that 
reside in Tennessee, enter %MS in the CLLI criteria field 


_ (Underscore) 


Place Holder 

Used to look for a known character in a field value 
Works on any field in the criteria box 

For example: to view a field value which has a 4 th character of 
'A', the entry in the criteria box would be A% where the 
underscore represents 3 spaces in this example. The % is a wild 
card and will show all values for this field that have a 4 th character 
of 'A'. 



Table 8 



[0136] Errors Grid Button : Errors grid button 916 returns the display back to usage 

grid display 900, shown in Figure 9. The fields on this screen can be sorted in either 
ascending or descending order by single clicking on a specific field name (i.e., CIC, 
CNPA, etc.) at the top of a column. A record can be displayed by highlighting it and 
double-clicking. The Usage Display Screen will be displayed. The order of the fields 
can be changed when viewing the grid. This is in addition to the procedure discussed 
in the group function. 
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[0137] Last Error Grid Button : Last error grid button 918 displays the last grid that 

was being worked on. 

[0138] Pending Transactions Button : Pending transactions button 920 is used to 

display the transactions for the current day which are displayed in the pending 
transaction screen 1300 in Figure 13.. The screen provides options to display: All 
Pending Transactions (includes everyone's); My Pending Transactions (only displays 
user's); All 'Disapproved' Pending Transactions, or My 'Disapproved 5 Pending 
Transactions, 

[0139] Hold Button : The hold button 922 is used to allow comments to be entered for 

an error record and/or added to an existing transaction. Hold is activated when an 
error record(s) or existing case is selected from Current folder, Hold folder, or Other 
folder in order to enter comments about the record. Comments should be entered to a 
record after an IBIS Case, TTS trouble ticket, or Subject Matter Expert (SME) 
referral has been issued. Also, each case may need subsequent comments added for 
historical purposes. 

[0140] Undo Hold Button : The unhold button 924 is used to return a record or group 

of records to Other. It does not release to pending transactions. 

[0141] Guarantee Button : Guarantee button 926 is used to update a case with 

comments for bill guarantee. It is similar in function to write-off button 928 described 
below. If the messages are too old to bill or the cases have outstanding tickets, 
guarantee button 928 allows statistics to be pulled for the bill guarantee report. 

[0142] Write-off Button : Write-off button 928 is used to produce a report for 

journalization of revenue that is billable but cannot be billed. The reasons for write- 
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offs could be due to one of the following: usage trying to bill to a disconnect account; 
usage trying to bill to an account with the wrong carrier ID and the new ID is 
unknown; or usage is too old to bill. 
[0143] Delete, Release, and Change Buttons : These buttons do exactly as the button 

implies. The function of each button is further described in Table 9. 



Button 


Function 


Delete 


The only time this button should be used is when the error does not 
represent billable usage: 
Duplicate record 
Test record 

Highlight the record/case and press Delete 

The 'Add Comment for Delete' screen will appear 

Enter reason(s) for the deletion and press OK 


Release 


Use this button when all corrections have been completed 
Highlight the record/case and press Release 
The 'Add Comment for Release' screen will appear 
The record(s) will release with the day's transactions 


Change 


Used to change an error record 

Highlight the record/case and press Change 

The 'Change Transaction Screen' will appear 

Make appropriate changes to the record and press apply 

The fields shaded gray can not be changed 

An occurrence on the Error Grid may have multiple records. To 

move from record to record, press the arrows in the lower bottom 

section of the Change Transaction Screen 



Table 9 



2. Building A Case Of Usage 

[0144] The follow procedures describe how to build a case of usage in the BRAVO 

system. The maximum number of lines that can be selected for one case is 20. 
However, if a case has more than 20 lines on the grid, fields not needed to identify the 
usage can be eliminated thereby reducing the number of distinct lines on the grid. 
This should free up some room for a few more lines. 
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[01 45] The following steps can be used to build a case of usage. 1 . Double-click on 

Other to get to the error grid Identify fields and values. 2. Manipulate the grid to see 
the fields and values to be worked with. 3. Select one or more lines on the grid The 
ability to select multiple lines by clicking and dragging, if adjacent, or by using the 
CTRL key plus clicking on the additional lines, if non-adjacent, is available. 4. Press 
the HOLD button a. Fill in the information in the pop-up box b. Open the drop down 
box for the Comment Type c. Select the type that is appropriate. Based on this 
selection, the remaining 2 boxes will be decided as shown in Table 10. 5. Enter 
description of any information associated with this group of usage in the Comments 
area a. Press OK b. The usage will leave the grid and the case will appear under Hold 
for that error code. 



If... 


Then.,. 


Selection "IBIS Case 
Sent To" is chosen 


Select drop down box for Send To 

Choose where the case was sent 

Enter the IBIS case number in the IBIS Case input field 


Selection "Pending CEO 
File Change" is chosen 


Must enter the NP A NXX in the input field on the right 
Do not enter anything in the Send To box 


Selection "Referred To" 
is chosen 


Choose Staff or Supervisor in the Send To box 
Do not enter anything in the 3 rd box 


Selection "Trouble 
Ticket To" is chosen 


A selection must be made for the Send To box 
the error processing system of the present invention 
IT 

Internal 

Enter the Trouble Ticket number in the input box 




Selection "Work Request 
Sent To" is chosen 


A selection must be made for the Send To box 
the error processing system of the present invention 
IT 

Enter the Work Request number in the input box 




Selection "Other" is 
chosen 


No entry is required in the Send To or Input box 



Table 10 
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B. Administrator GUI 

[01 46] This section describes the BRAVO administrator GUI and the steps an 

administrator takes to approve or disapprove a transaction. Thresholds may be set for 
transactions submitted by BRAVO users. The fields in the transaction for which 
thresholds have been established are: Message Days (age of usage); Minutes of Use 
(MOUs); Messages; Records; and Pegs. 

[0147] On a daily basis, administrators should view the transactions from all sites that 

exceeded thresholds. Using the administrator GUI, an administrator can approve, 
disapprove or reset transactions. If nothing is done to a transaction requiring approval, 
it will remain on the "Not Approved Transactions" screen until the administrator 
performs this function. 
1. Main Screen 

[0148] Figure 14 shows main screen 1400 of the BRAVO administrator GUI. This 

screen provides access to many features. Tab 1402, Transaction Approval/Listing 
screen (default), opens to display all the transactions that have not yet been touched 
by the administrator. The version of the application is displayed at the bottom of the 
screen. Several displays can be viewed by the administrator from this screen which 
include site, user, transaction, usage type, and transaction type, described in Table 11. 
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Selection 


Description 


Site (drop-down box) 


Provides the option of selecting all sites (default) or an individual site 


User (drop-down 
box) 


Provides the option of selecting all users (default) or an individual 
user 


Show (Transaction) 
(radio button) 


Provides the option of selecting transactions that have been: Not 
Approved (default); Disapproved; Approved; or All (includes Not 
Approved, Disapproved, and Approved) 


Usage Types (drop- 
down box) 


Provides the option of selecting the type of usage: Detail; Meet Point 
Billing (MPB); All (includes both Detail and MPB) (default) 


All Trans Types 
(drop-down box) 


Provides the option of selecting the type of transaction: All Trans 
Types - displays all the different types of transactions (default); Bill 
Guarantee; Change; Delete; Release; and Write-Off 


Approval Buttons 


Provides the option of approving, disapproving, or resetting a 
transaction. The button options change depending on the Show 
(Transaction) option selected: Not Approved - Approve button is 
activated; Disapproved - Approve and Reset buttons are activated; 
Approved - Disapproved and Reset buttons are activated; All - no 
buttons are activated 



Table 11 



[0149] Tab 1404 displays the thresholds in a transaction approval maintenance 

screen, shown in Figure 15. This screen allows the administrator to maintain the 
various thresholds for the system. 

2. Detail Display Screen 

[01 50] To get a detail display screen of any transaction, as shown in Figure 1 6, 

double click on the individual transaction. Details about the transaction will be 
displayed at the top of the screen and a record layout will be displayed at the bottom 
of the screen. This is only a sampling. Not all the records within the transaction will 
be available only the first 50 are displayed. The detail display screen is available for 
all transactions whether they are Not Approved, Disapproved, or Approved. 

3. Procedures 

[0151] The following are steps for accessing the error processing system of the 

present invention Administration GUI and approving/disapproving transactions. 
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[01 52] 1 . Access GUI : Select the error processing system of the present invention 

Administration GUI from the desktop, a. Enter CUID in the User Name; b. Enter 
password in appropriate field; c. Either press <enter> or the Login button 

[0153] 2. Select Specific Criteria : On the Transaction Approval/Listing screen, select 

the site and user as appropriate, a. Choose the transaction listing to be viewed by 
selecting Not Approved, Disapproved, Approved, or All from the display located on 
the right side of screen; b. Choose the transaction type by selecting Detail, MPB, or 
All from the display located on the right side of the screen; c. Choose the transaction 
type from the drop-down box located on the right side of the screen. 

[01 54] 3 . Check Transaction Details : Select a specific transaction to be viewed and 

double click, a. Press the Print button to print the screen; b. Press the Copy button to 
copy the screen for use in a document, i.e., TTS trouble ticket, e-mail, etc.; c. Press 
Close button to return to the Main Screen. 

[0155] 4. Perform Approval Function : Select one of the buttons located on the right 

side of the screen to either Approve, Disapprove, of Reset the transaction as described 
in Table 12. 

[0156] 5. Exit The Application : Press the Exit button to exit the error processing 

system of the present invention Administration GUI 



If... 


Then... 


the administrator 
disapproves a 
transaction 


the administrator is required to enter a comment stating reason 

Note: Comments for each transaction/case is at the bottom of the 
transaction approval screen and is a history of comments 



Table 12 
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C. Reports 

[01 57] The BRAVO Reporting Wizard provides the ability to review reports for: 

Users and for the System. The reports are available by site, date span, charge 
NPA/NXX, originating NPA/NXX, Detail, Meet Point Billing, etc. 
1. User Reports 

[0158] The available User Reports are as follows: User Transaction Report by 

Employee with Comments; User Transaction Report by Employee with Comments 
and Case Definitions; User Transaction Report by Site with Comments; User 
Transaction Report by Site with Case Definitions; BRAVO Usage - Charge 
NPA/NXX; BRAVO Usage - Originating NPA/NXX; BRAVO Usage - Terminating 
NPA/NXX. Each of these reports is described in greater detail below. 

[0159] The User Transaction Report by Site/Employee with Comments (Figure 

17) provides a listing of transactions performed by each BRAVO Accounting 
Assistant for a particular site and/or Employee within a selected date range. The 
report is separated by error code with subtotals including message count, MOU count, 
Case number, Start and Ending date range, status, and comments from each 
Accounting Assistant. At the end of the report is a subtotal for the site which includes 
total number of errors transacted, message count, MOU count, Start and Ending date 
range. 

[0160] The User Transaction Report by Site/Employee with Comments and 

Case-Definitions (Figure 18) contains the same information as the last report except 
it also adds a Case-Definition for each record found. 

[0161] BRAVO CATTS Usage - Charge NPA/NXX (Figure 19) provides errors 

codes by Charge NPA/NXX within a specified date range. Other information on the 
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report includes CLLI, Office ID, CIC, Record Type, NPA/NXX, CABS Traffic Type, 
Trunk Group Number, Case number, message count, and MOU count. A Grand Total 
of messages and MOUs is also calculated. 

[0162] BRAVO CATTS Usage - Originating NPA/NXX (Figure 20) provides error 

codes by originating NPA/NXX within a specified date range. Other information on 
the report includes CLLI, Office ID, CIC, Record Type, NPA/NXX, CABS Traffic 
Type, Trunk Group Number, Case number, message count, and MOU count. A Grand 
Total of messages and MOUs is also calculated. 

[0163] BRAVO CATTS Usage - Terminating NPA/NXX (Figure 21) provides 

error codes by terminating NPA/NXX within a specified date range. Other 
information on the report includes CLLI, Office ID, CIC, Record Type, NPA/NXX, 
CABS Traffic Type, Trunk Group Number, Case number, message count, and MOU 
count. A Grand Total of messages and MOUs is also calculated. 
2. System Reports 

[0164] The available System Reports are as follows: Delete Summary Report; Write- 

off Summary Report; Transmission Reports; Aging - MOU 15-60-90 Report; Aging - 
Pegs 15-60-90 Report; Aging - Usage Cases On Hold other than IBIS; Aging Bill 
Guarantee IOS/72V; Aging Bill Guarantee OTS/CABSTT; Aging DA vs. Other; 
Error Master File - All; Error Master File - MPB; Transacted and Untouched Usage 
other than IBIS. Each of these reports is described in greater detail below. 

[01 65] The Delete Summary Report (Figure 22) provides error codes that have been 

deleted for either Detail or Meet Point Billing (MPB) usage. The report is selected by 
site and starting month through ending month. Each month will appear on a separate 
page of the report. When displayed on the screen, the ending month appears first and 
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the starting month will be the last page of the report. A Grand Total is reported on the 
last page of the report which includes message count and MOU count. The report 
contains the error code, message count, MOU count, Status, and Start and End Dates. 

[0166] The Write-Off Summary Report (Figure 23) provides a listing of all the 

usage written off for a specific period of time. The report is selected by site and 
starting month through ending month. Each month will appear on a separate page of 
the report. When displayed on the screen, the ending month appears first and the 
starting month will be the last page of the report. A Grand Total is reported on the last 
page of the report which includes message count and MOU count. The report contains 
the error code, message count, MOU count, Status, and Start and End date. 

[0167] The Transmission Reports (Figure 24) provides several options to select 

concerning error code information. The reports are site and transmission date specific. 
The error code information can be selected by: Usage type - Detail or MPB; 
Transmission Type - Load or Correction; and Group By - Error Code or Carrier. 

[0168] Each report contains Carrier ID, error code, record count, message count, 

MOU count, Peg count, and Start and End Date. Carrier subtotals are provided and a 
Grand Total for the site is located at the end of the report. If Transmission Type is 
Load, the cycle number is provided in the header of the report. 

[01 69] The MOU 15-60-90 Report (Figure 25) provides a detailed listing of usage 

information where minute-of-use is greater than 4000. The report lists the Error-Code, 
CIC, Trunk-group, LATA, and a count of Minutes-of-Use by breaking this field down 
in increments of 0-to-15 ? 16-to-60, 61-to-90, and greater than 90 days old. The report 
is sorted in descending order by the 16-to-60 day old increment. 
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[0170] The PEGS 15-60-90 Report (Figure 26) provides a detailed listing of usage 

information where Pegs is greater than 1000. The report lists the Error-Code, CIC, 
Trunk-group, LATA, and a count of Minutes-of-Use by breaking this field down in 
increments of 0-to-15, 16-to-60/61-to-90, and greater than 90 days old. The report is 
sorted in descending order by the 16-to-60 day old increment. 

[0171] The Aging - DA vs. Other Report (Figure 27) gives a detailed listing of 

usage information for the site that the user specifies. The report lists the Traffic-type, 
Error-Code, LATA, and a count of the messages which is broken down in increments 
of 0-to-15, 16-to-60, 61-to-90, and greater than 90 days old. The report is sorted in 
descending order according to the 16-to-60 field and is grouped into separate sections 
for DA, and all Other traffic types. 

[0172] The Transacted and Unworked Usage Other than IBIS Report (Figure 28) 

gives a detailed listing of usage information, other than IBIS, that has never before 
been seen or worked. The user must specify the site which they want to review. The 
report lists the Error-Code, CIC, TTS#, if one exists, Comment-Type, and a count of 
the Messages, Minutes, and Pegs for a each record. The report is sorted and grouped 
by Error-code with the appropriate subtotals, and grand total listed for messages, 
minutes and pegs. 

[0173] The Error Master File - MPB Report (Figure 29) provides a total of all the 

Meet Point Billing error codes for a specific site. The report contains the error code, 
description of the error, cycle number in which the error occurred, Peg count, 
message count, and MOU count. A Grand Total of the number of error codes, Peg 
count, message count, and MOU count is located on the last page of the report. 
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[0174] The Usage Cases On Hold Report (Figure 30) provides cases on hold for a 

specific site. The report contains information about the current case information 
placed on hold by the Accounting Assistants. The report itself contains the IBIS 
Case#, BRAVO Case# ? error-code, CIC, Start-MsgDate, End MsgDate, count of 
Minutes of Use, and a count of the Pegs associated with that particular case. Report 
Parameters; Site; Usage type - Detail or MPB. 

[0175] The Aging Bill Guarantee IOS/72V Report (Figure 31) provides record-type 

72V information for a specific site. The report contains the error code, CIC, LATA, 
Case Number, message count, MOU count, and Start and End dates. A Grand Total 
for message count, MOU count, the earliest Start date, and the latest End date are 
located at the end of the report. 

[01 76] The Aging Bill Guarantee OTS/CABSTT Report (Figure 32) provides 

Traffic-Type 86 information for a specific site. The report contains the Error-Code, 
CIC, LATA, Independent Indicator, BRAVO Case #, Message count, MOU count, 
and Start and End dates. A Grand Total for message count, MOU count, the earliest 
Start date, and the latest End date are located at the end of the report. 

[001 05] The foregoing disclosure of the preferred embodiments of the present 

invention has been presented for purposes of illustration and description. It is not 
intended to be exhaustive or to limit the invention to the precise forms disclosed. 
Many variations and modifications of the embodiments described herein will be 
obvious to one of ordinary skill in the art in light of the above disclosure. The scope 
of the invention is to be defined only by the claims appended hereto, and by their 
equivalents. 
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Further, in describing representative embodiments of the present invention, 
the specification may have presented the method and/or process of the present 
invention as a particular sequence of steps. However, to the extent that the method or 
process does not rely on the particular order of steps set forth herein, the method or 
process should not be limited to the particular sequence of steps described. As one of 
ordinary skill in the art would appreciate, other sequences of steps may be possible. 
Therefore, the particular order of the steps set forth in the specification should not be 
construed as limitations on the claims. In addition, the claims directed to the method 
and/or process of the present invention should not be limited to the performance of 
their steps in the order written, and one skilled in the art can readily appreciate that 
the sequences may be varied and still remain within the spirit and scope of the present 
invention. 
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